check out this series of posts by jasper st. pierre et al about how the x window system works, plus some 2d rasterisation techniques:

https://magcius.github.io/xplain/article/index.html

the figures are demos that use a tiny canvas-based x server they wrote in js!

check out this fascinating post by raph levien about how vsync works (defer swapping until scanout completes, but only block when actually writing to the new backbuffer), how double and triple buffering typically work, and how these techniques improve throughput at the expense of latency, jitter, and/or power consumption.

vsync means rendering and running your updates as early as possible, right after scanout completes. it’s simple, but it makes the frame you present as stale as possible.

“frame pacing” means rendering and running your updates as late as possible, right before the next scanout starts. it makes the frame you present as fresh as possible, but it’s more complicated, because you need to estimate how long your work will take.

see also, how the compositors we have today regress on latency compared to “racing the beam”.

see also, why it’s surprisingly hard to write an app that resizes smoothly on the left edge.

• webkit has ports, which are adaptations of the engine to various platforms
• wpe is a “platformless” webkit port, designed to support as many embedded platforms as possible
• these platforms are wpe backends, and now wpe has a backend (and widget) for android

history of the android webview

• originally system, webkit-based (<= jellybean, 2008-2013)
• then system, chromium-based (= kitkat, 2013-2014)
• now unbundled, chromium-based (>= lollipop, 2014-)

why webkit on android?

• android has wide hardware support via vendor BSPs
• android is a relatively stable platform on the app-facing side
• webkit improves web engine diversity
• using webkit avoids reliance on OS updates for webview functionality

new WPEPlatform API

• more type-safe, using GObject instead of plain C
• better documentation and linting

next steps

• example quality-of-life improvements: mimic the system WebView API
• example reduce binary sizes: making components and features optional

“render pacing”

• like frame pacing? not sure
• https://raphlinus.github.io/ui/graphics/gpu/2021/10/22/swapchain-frame-pacing.html
• https://raphlinus.github.io/ui/graphics/2020/09/13/compositor-is-evil.html

• web components are used for cross-framework UI libraries, micro-frontends
• people want to mix multiple versions of a custom element with the same name
• prior art: scoped element registries
  • tricky to use, non-declarative, and no support for hydration

imagine

• customElements.define('name', Name, {version: 2})

next steps

• complete and submit the proposal
• build a polyfill
• demo it with a real UI library

how does this compare to appending the version to the element name itself?

• annevk: The main reason for scoping is that you might have multiple libraries that conflict in some way and the libraries are not designed to account for conflicts.
• annevk: If you control all the code there's not much need for this I think.

what is jsr and why does it exist?

• a registry that lives alongside npm (the registry), but does not replace it
• jsr aims for open governance, unlike npm which is now owned by microsoft
  • caveat: currently still owned by deno, but working towards own foundation
• built-in support by yarn and pnpm, but not npm (the package manager)
• has the backing of key people involved with npm, node.js, deno, vue.js, vite

cool features

• supports typescript
• supports auth without static secrets (oidc tokens)
• supports artifact provenance when building and releasing in ci
• serves up .d.ts files and source maps and documentation online

how impls get packages from jsr

• for npm-compatible clients, point to npm.jsr.io in .npmrc
• yarn, pnpm, jsr: supported out of the box
• deno: supported out of the box (gets sources, not tarballs)

future steps

• allowing import from https in browsers (currently not allowed for cost/infra reasons)

https://jsr.io

what is wintercg wintertc?

• wintertc defines the subset of apis supported by all runtimes
• the goal is to interoperably expand that subset over time

finding a standards body

• W3C community groups can’t publish specs, so we need to find a standards body proper
• invited experts are important because you don’t want to limit collaboration to dues-paying companies
• ECMA TC55

current work

• building a wintertc test suite, subset of wpt
  • sometimes need to modify tests to be compatible with the minimum common api
  • want to work upstream. how do we do this without forking the whole wpt suite?
• decoupling upstream specs from the web platform where possible (e.g. fetch)
  • fetch has a lot of web-specific concerns that don’t apply on server-side
  • there is no current page, cookie jar, cross-site security, atomic redirect handling
  • need to add cookies to the client-facing API, because there’s no cookie jar
  • want to add control over protocol (h1/h2/h3), mTLS, http proxies, CA certificates, etc
  • want to work upstream. how do we do this without forking the whole fetch spec?
• adding functionality (e.g. streaming data in web crypto)

minimum common api

• subset of [Exposed=*], which is in turn the subset allowed in any shadow realm
• typically includes compute-only APIs and generally useful things like async I/O
• what can wpt authors do to ensure they adhere to the minimum common api?
  • try to write your tests as .any.js, not as .html
  • currently you can check if you are server-side-compatible by landing your tests and checking wpt.fyi
  • they are working on ways to make this easier, such as running wpt tests locally in deno
• what about the dom? wouldn’t it be useful to manipulate dom trees server-side?
  • this is complicated, because it’s tangled up in things like html parsing

additional conformance levels

• useful for optional feature sets that we don’t want to mandate across all runtimes
• for example, a graphics feature set would have WebGPU, OffscreenCanvas, etc

join the meetings!

• restricted to ecma members and tc55 invited experts for ipr reasons
• buuuuut they’re trying to make membership as easy as possible

juicy numbers (output size, mean runtime, mean rss)

• hi_bun 97M 55ms 75MB
• hi_deno 100M 16ms 31MB
• hi_porffor 20K <1ms 1.4MB
• hi_javy 1.3M - - (javy is a js to wasm compiler)
• hi_porffor_wasm 4.0K - -
• no benchmark demo for the last two bc wasm is hard to run server-side (for now)
• no benchmark demo for quickjs, another ahead-of-time compiler?

github canadahonk/porffor

• porffor is completely written in ts/js, for better or worse

current limitations

• with is a no-op for now
• eval is unsupported for now - it’s possible but annoying to impl
• takes advantage typescript type annotations
• no gc or fancy allocator - best for short-running use cases like aws lambda

impl challenges

• things that are inexplicably underspecified, like Date.parse() or Array#sort()
• runtime code evaulation (as above) - would need to ship a mini engine in output
• optimising prototypes without breaking shit